AD-A151  844  DEVELOPING  AN  AUTOMATED  TECHNIQUE  FOR  TRANSLATING  A  1/2 

RELATIONAL  DATABASE  I.  .  OJ>  AIR  FORCE  INST  OF  TECH 
URIGHT-PATTERSON  AFB  OH  SCHOOL  OF  ENGI.  .  E  V  ALV 
UNCLASSIFIED  DEC  84  AFIT/GCS/NATH/84D-4  F/G  9/2  NL 


*um  AUiUmxjiU  i'iXJHNIQUE  FOR 


TRANSLATING  A  RELATIONAL  DATABASE  INTO 
AN  EQUIVALENT  NETWORK  ONE 
THESIS 

Slsayed  Yaser  Aly 
Maj . ,  Egyptian  Ariny 

AFIT/GCS/MATH/84D-4 


Thia  document  ha»  bssa  aqppccnrsd 
for  public  rsieass  and  sa Is*  Ml 
dUtrtbuttau  Is  mJbnUsdi 

DEPARTMENT  OF  THE  AIR  FORCE 


DTIC 

electe 


APR  0 1  1985 j 

E 


AIR  UNIVERSITY 


AIR  FORCE  INSTITUTE  OF  TECHNOLOGY 


Wright-Patterson  Air  Force  Base,  Ohio 

85  03  13  254 


DEVELOPING  AN  AUTOMATED  TECHNIQUE  FOR 
TRANSLATING  A  RELATIONAL  DATABASE  INTO 
AN  EQUIVALENT  NETWORK  ONE 
THESIS 

Elsayed  Yaser  Aly 
Maj . ,  Egyptian  Amy 

AFIT/GCS/MATH/84D-4 


Approved  for  public  release;  distribution  unlimited 


AFIT/GCS/MATH/ 84D-4 


€• 


DEVELOPING  AN  AUTOMATED  TECHNIQUE  FOR  TRANSLATING 
A  RELATIONAL  DATABASE  INTO  AN 
EQUIVALENT  NETWORK  CNE 

THESIS 

Presented  to  the  Faculty  of  the  School  of  Engineering 
of  the  Air  Force  Institute  of  Technology 
Air  University 

In  Partial  Fulfillment  of  the 
Requirements  for  the  Degree  of 

Master  of  Science  _ 


by 

Elsayed  Yaser  Aly 
Maj.,  Egyptian  Army  j 

Ad. 

December  1984 

Approved  for  public  release;  distribution  unlimited. 


Preface 


The  purpose  of  this  study  was  to  develop  an  automated  technique  for 
translating  a  relational  database  into  an  equivalent  network  one.  This 
technique  is  the  major  part  in  creating  a  multi-model  database  management 
system  from  a  network  one  and  that  will  enable  the  users  to  implement  both 
relational  and  network  databases  via  one  database  management  system. 

The  developed  technique  was  used  to  translate  a  relational  schema  into 
a  network  one .  The  generated  network  schema  had  the  optimum  number  of 
record  types  and  sets,  had  no  redundancy,  and  preserved  the  functional 
dependencies  of  the  relational  schema. 
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in  times  of  need.  I  also  wish  to  thank  Dr.  Gary  Lament  and  Dr.  Thcmas 
C.  Hartrum  for  reviewing  my  thesis  and  for  their  assistance  and  suggestions. 

Finally,  I  wish  to  express  my  sincere  gratitude  to  my  father  who 
taught  me  how  to  do  everything  as  perfect  as  I  can  and  encouraged  me  to 
continue  learning  all  my  life.  Also,  I  wish  to  thank  my  wife  Samya  for 
her  understanding  and  concern  on  these  many  nights  when  I  was  tied  to  my 
desk  or  my  computer  with  work. 
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Abstract 


This  thesis  developed  an  automated  technique  for  translating  a  rela¬ 
tional  schema  into  an  equivalent  network  one.  In  addition  to  the  usual 
translation  applications,  this  technique  is  the  -rajor  step  towards  develop¬ 
ing  the  multi-model  .data  base  management  system  which  enables  implement  Lag 
both  relational  and  network  databases  via  one  system,  allows  the  use  of 
either  relational  or  .network  commands,  solves  the  problem  of  converting 
applications,  and  eases  the  communication  between  data  base  ranagement 
systems. 

Reviewing  the  previous  efforts  in  that  field,  there  are  two  algorithms 
that  were  developed  for  the  same  objective.  Each  one  was  discussed, 
explained,  and  used  to  solve  an  illustrative  example.  Both  algorithms  were 
compared  and  one  of  them  was  chosen  as  a  basis  for  developing  the  automated 
technique. 

The  chosen  algorithm  was  modified  to  suit  the  requirements,  and  analyzed 
and  decanposed  using  the  SADT.  The  automated  technique  was  developed  and 
coded  in  PASCAL.  In  its  development,  it  was  considered  to  be  user  friendly, 
and  to  produce  the  network  schema  in  a  suitable  format.  The  developed 
technique  was  tested  and  implemented  using  a  relational  schema  in  the  third 
normal  form.  The  resulting  network  schema  was  efficient,  nonredundant,  and 
had  the  minimum  and  necessary  number  of  record  types  and  sets  as  it  was 
supposed  to  be. 

Several  conclusions  were  reached  during  the  course  of  study,  and  seme 
recommendations  'were  proposed  for  further  study  according  to  the  assumptions 
listed  initially. 


I.  Introduction 

1.1  Background 

In  recent  years  there  has  been  a  rapid  growth  in  the  use  of  large 
database  systems.  The  network  model  is  now  in  wide-spread  use.  The 
relational  model  was  introduced  and  rapidly  developed  in  the  past  decade 
Both  have  attracted  the  most  attention  among  the  various  models  of  data¬ 
base  systems.  The  relational  model  appears  to  be  easier,  siitpler,  to 
provide  more  data  independence,  and  to  be  superior  in  terms  of  the 
logical  description  of  databases,  whereas  the  network  model  is  more  ef¬ 
ficient  of  space  and  time,  and  provides  a  more  natural  structure  for  the 
modelling  of  the  world  (11) .  Both  data  models  are  useful  and  important 
but  neither  is  best  for  all  applications. 

A  DBMS  is  designed  to  handle  the  applications  of  only  one  database 
model.  It  presents  the  following  difficulties  (11:82) : 

-  The  suitable  data  model  for  an  application  may  be  different 
from  the  existing  DBMS. 

-  It  is  difficult  for  a  DBMS  to  access  the  data  maintained  by  a 
different  DBMS. 

-  Conversion  of  all  applications  may  be  necessary  if  a  different 
DBMS  is  installed. 

The  term  "multi-model  DBMS"  is  used  to  identify  that  the  DBMS  can 
handle  more  than  one  database  model.  This  type  of  DBMS  eases  many  pro¬ 


blems  such  as  (22:82) : 


-  The  database  administrator  can  choose  the  data  model  that 
suits  his  application  and  a 1 lews  him  to  be  more  productive. 

-  It  solves  the  problem  of  converting  applications  from  one 
data  model  to  another. 

-  It  eases  the  ccrmmications  between  the  different  DBMSs. 

-  The  database  administrator  can  incorporate  the  advantages  of 
both  relational  and  network  models  by  using  the  first  one  for 
describing  the  database  and  the  second  one  for  implementing  it. 

-  The  user  can  access  the  database  using  either  relational  or  net¬ 
work  ccntnands. 

To  achieve  a  multi-model  DBMS,  it  is  required  to  provide  the  uni¬ 
model  DBMS  with  an  automated  technique  to  translate  both  the  data  model 
schema  and  the  data  manipulation  commands  of  one  database  model  to  another 
that  suits  the  uni-model  DBMS.  For  example,  if  the  DBMS  is  a  network 
one,  the  automated  technique  has  to  support  the  translation  of  a  rela¬ 
tional  schema  to  an  equivalent  network  one  and  the  translation  of  the 
relational  commands  to  the  network  commands. 

1.2  Problem  Statement 

It  seems  reasonable  to  consider  the  problem  of  translating  a  rela¬ 
tional  model  into  a  network  one  for  the  following  reasons: 

-  The  relational  database  enables  us  to  incorporate  the  recent 
results  in  design  theory  such  as  the  normal  forms  and  the  loss¬ 
less  join  property.  For  this  reason  the  relational  model  is 
widely  used  now  more  than  the  other  data  models. 

-  Large  percentage  of  the  existing  DBMSs  are  network  systems  since 
the  network  model  was  developed  earlier  than  the  relational  one. 


-  Other  researchers  (13; 19)  have  considered  the  problem  of  trans- 


m 


lating  a  network  model  into  a  relational  one. 

-  Another  researcher  (9)  has  considered  the  mapping  between  rela¬ 
tional  and  network  operators. 

Translating  a  relational  schema  into  an  equivalent  network  one 
enables  the  database  administrator  to  implement  a  relational  database  via 
a  network  DBMS.  On  the  other  hand,  translating  the  relational  data 
manipulation  commands  into  network  corrmands  will  provide  the  ability  to 
handle  the  database  using  either  the  relational  commands  or  the  network 
conmands.  Both  translations  are  necessary  to  achieve  the  multi-model 
DBMS. 

The  problem  that  will  be  discussed  in  this  thesis  is  to  develop  an 
automated  technique  for  translating  a  relational  database  into  an  equiva¬ 
lent  network  one. 

1.3  Scope 

Translating  a  relational  database  into  an  equivalent  network  one  has 
to  be  done  through  the  following  steps: 

1.  If  the  relational  database  is  implemented  via  a  relational  DBMS, 
it  needs  a  program  to  read  its  structure. 

2.  If  it  is  not  in  the  third  normal  form,  it  needs  to  be  converted 
to  the  third  normal  form  using  the  algorithms  in  (16; 20; 21) . 

3.  Translating  the  relational  schema  into  an  equivalent  network 
one. 

4.  Implementing  the  network  schema  via  a  network  DBMS. 

5.  Reading  the  data  from  the  relational  database  and  loading  it  in 
the  appropriate  record  types  in  the  network  database. 
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Besides  that,  translating  the  relational  commands  to  network  commands 
is  necessary  to  completely  achieve  the  multi-model  DBMS. 

If  the  problem  is  that  there  is  a  designed  relational  schema  in  an 
organization  which  has  only  a  network  DEMS,  the  solution  is  to  develop  an 
automated  technique  to  translate  it  to  an  equivalent  network  one  in  order 
to  implement  it  via  the  existing  DBMS.  This  is  simpler  and  easier  than  to 
repeat  the  design  process  completely  which  is  more  expensive  and  needs  a 
long  time. 

The  scope  of  this  thesis  investigation  is  to  develop  an  automated 
technique  for  translating  a  relational  schema  into  an  equivalent  network 
one.  This  solves  the  above  problem  and  at  the  same  time  it  is  the  major 
step  in  translating  a  relational  database  to  a  network  one. 

1.4  Objectives 

The  objective  of  this  thesis  effort  is  to  develop  an  automated 
technique  for  translating  a  relational  schema  into  an  equivalent  network 
one.  The  following  points  will  be  considered  during  developing  this 
automated  technique: 

1.  It  should  be  able  to  deal  with  a  relational  schema  of  a  finite 
number  of  attributes  and  relations. 

2.  It  should  be  user  friendly.  This  means  that  the  user  will  input 
the  required  data  of  the  relational  schema  to  the  automated 
technique . 

3.  The  output,  which  is  the  network  schema,  should  be  in  an  under¬ 
standable  form.  It  is  difficult  to  give  the  output  in  a  graphical 
form  because  the  number  of  record  types  and  the  owner-member 
relationships  between  them  vary  from  one  schema  to  another.  The 
automated  technique  should  overcome  this  difficulty  and  output  the 


network  schema  in  an  easy  to  understand  form. 

4.  The  automated  technique  shculd  provide  an  efficient  network 
schema  with  no  redundancy,  with  the  minimum  number  of  record 
types,  and  with  the  minimum  number  of  owner-member  sets  that 
achieve  the  equivalence  to  the  input  relational  schema. 

This  objective  will  be  achieved  through  the  following  steps: 

1.  Studying  the  previous  efforts  in  this  area. 

2.  Choosing  a  suitable  algorithm. 

3.  Developing  the  automated  technique  for  translating  a  relational 
schema  into  a  network  one  using  the  modified  algorithm. 

4.  Testing  the  automated  technique  using  a  relational  schema  to  be 
translated  into  a  network  one. 


1.5  Assumptions 

The  first  assumption  is  that  the  relational  schema,  that  will  be  trans¬ 
lated  into  an  equivalent  network  one,  is  in  the  third  normal  form,  have 
the  lossless  join  property,  and  embody  the  functional  dependencies  as  keys 
(10) .  There  are  many  algorithms  to  generate  such  a  relational  schema 
(16; 20; 21) . 

The  second  assumption  is  that  the  automated  technique  will  consider 
the  translation  process  only.  If  the  relational  database  is  already  imple¬ 
mented  via  a  relational  DBMS,  then  another  software  is  responsible  to  read 
its  structure  and  pass  it  to  the  translation  software.  Also,  it  is  assumed 
that  another  software  will  take  the  network  schema  as  its  input  and  imple¬ 
ment  it  via  a  network  DBMS. 


1.6  Order  of  Presentation 

The  necessary  concepts  of  the  relational  and  network  data  models  will 
be  discussed  in  the  following  chapter,  that  is  Chapter  II.  Also,  it 
includes  a  comparison  between  the  two  models  and  how  to  achieve  the  multi¬ 
model  DBMS  from  either  the  relational  or  the  network  model. 

Chapter  III  includes  a  summary  of  the  previous  work  done  in  that 
field.  There  are  tvo  algorithms  that  were  already  developed  for  this 
purpose.  Each  one  is  discussed  in  detail  and  used  to  solve  an  example. 

Both  solutions  are  compared  and  one  algorithm  is  chosen  for  developing  the 
automated  technique. 

In  Chapter  IV,  the  chosen  algorithm  is  modified  to  be  suitable  for 
programming.  Then,  the  modified  algorithm  is  analysed  and  decomposed  using 
the  SADT  (Structured  Analysis  and  Design  Technique) ,  and  the  structure 
charts  are  drawn.  The  algorithm  for  each  module  is  designed  and  the 
complete  automated  technique  is  developed.  Also,  the  chapter  includes  the 
results  of  testing  and  implementing  the  automated  technique. 

The  conclusions  and  recommendations  are  presented  in  Chapter  V. 
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II.  Relational  and  Network  Data  Models  (4; 7; 10) 


2.1  The  Relational  Model 

2.1.1.  Basic  definitions.  The  basic  component  of  a  relational  data¬ 
base  is  the  relation  which  is  in  the  form  of  a  table.  Each  column  in  this 
table  has  a  unique  name  which  is  called  the  attribute  name.  Each  attribute 
has  its  domain.  Any  value  for  that  attribute  in  the  table  is  drawn  from 
its  domain.  Each  row  of  the  table  is  called  a  tuple.  It  is  an  ordered 
set  of  attribute  values  and  this  set  is  unique.  The  relational  scheme  for 
a  relation  is  the  relation  name  and  the  attribute  names.  A  relational 
database  is  a  set  of  relations  and  a  relational  schema  is  the  set  of 
relational  schemes  corresponding  to  the  given  set  of  relations  (10) . 

2.1.2  The  Relational  Operators.  The  relational  operators  are  the 
project,  select,  and  join.  They  are  denoted  by  rr,  a,  and  *  respectively. 
The  operands  of  these  operators  are  the  relation  schemes.  A  relational 
expression  is  evaluated  by  substituting  the  relations  for  the  relation 
schemes  and  applying  the  operators  according  to  their  definitions. 

The  select  operator  constructs  a  new  table  by  taking  a  horizontal  sub¬ 
set  of  the  existing  table,  that  is,  all  the  rows  that  satisfy  seme  condi¬ 
tion.  The  project  operator  forms  a  vertical  subset  of  an  existing  table 
by  extracting  specified  columns  and  removing  any  redundant  rows  in  the 
extracted  table.  If  two  tables  each  have  a  column  defined  over  sane  cannon 
domain,  they  may  be  joined  over  those  two  columns.  The  result  of  the  join 
is  a  new  table  in  which  each  row  is  formed  by  concatenating  two  rows,  one 
from  each  table,  such  that  the  two  rows  have  the  same  value  in  those  two 


columns  (4)  . 


(a)  Functional  Dependency 

In  a  relation  R,  attribute  Y  is  functionally  dependent 
on  attribute  X  if  and  only  if,  whenever  two  tuples  of  R  agree  on  their  x- 

value,  they  also  agree  on  their  Y-value.  This  is  denoted  by  X - >Y. 

Attribute  Y  is  fully  functionally  dependent  on  attribute  X  if  it  is  func¬ 
tionally  dependent  on  X  and  not  functionally  dependent  on  any  proper  sub¬ 
set  of  X. 

(b)  Multivalued  Dependency 

Given  a  relation  R  with  attributes  A,  B,  and  C,  the  multi¬ 
valued  dependency  A  — >  — >B  holds  if  and  only  if  the  set  of  B-values 
matching  a  given  (A-value,  C-value)  pair  in  R  depends  only  on  the  A-value 
and  is  independent  of  the  C-value.  A,  B,  and  C  may  be  composite.  Multi¬ 
valued  dependency  is  denoted  by  MVD. 

(c)  Join  Dependency 

Relation  R  satisfies  the  join  dependency  (X,  Y,  Z) 

if  and  only  if  it  is  the  join  of  its  projections  on  X,  Y,  ,  Z  where 
X,  Y,  ...  Z  are  subsets  of  the  set  of  attributes  of  R.  It  is  denoted  by 
JD  and  written  (X,  Y,  ...Z)  (7). 

2.1.4  Normal  Forms  (4;7;10) 

A  relation  R  is  in  the  first  normal  form  (INF)  if  and  only  if 
all  underlying  domains  contain  atonic  values  only.  It  is  in  the  second 
normal  form  (2NF)  if  and  only  if  it  is  in  INF  and  every  nonkey  attribute  is 
fully  dependent  on  the  primary  key.  If  it  is  in  2NF  and  every  nonkey 
attribute  is  nontransitively  dependent  on  the  primary  key,  then  the  relation 
R  is  in  the  third  normal  form  (3NF) . 


A  relation  R  is  in  the  Boyce/Codd  Normal  Form  (BCNF)  if  and 
only  if  every  determinent  is  a  candidate  key.  Determinent  is  an  attribute 
on  which  some  other  attribute  is  fully  functionally  dependent. 

A  relation  R  is  in  the  fourth  normal  form  (4NF)  if  and  only 
if,  whenever  there  exists  MVD  in  R,  say  A  — >  — >  B,  then  all  attributes 
of  R  are  also  functionally  dependent  on  A.  It  is  in  the  fifth  normal  form 
(5NF)  if  and  only  if  every  join  dependency  in  R  is  implied  by  the  candidate 
key  of  R. 

The  different  types  of  normal  forms  can  be  obtained  for  a 
given  relation  using  the  nonloss  decomposition  technique.  Starting  with 
an  original  relation  and  a  set  of  constraints,  the  relation  can  be  reduced 
to  a  collection  of  relations  that  are  equivalent  to  the  original  one  and 
in  some  way  preferable  to  it.  The  constraints  are  used  as  a  guide  during 
the  decomposition  process.  This  process  can  be  done  as  follows: 

-  The  projections  of  the  INF  relation  to  eliminate  any  non  full  FDs 
will  produce  2NF  relations. 

-  The  projections  of  2NF  relations  to  eliminate  any  transitive 
dependency  will  produce  3NF  relations. 

-  The  projections  of  3NF  relations  to  eliminate  any  remaining  FDs  in 
which  the  determinent  is  not  a  candidate  key  will  produce  a  collec¬ 
tion  of  BCNF  relations. 

-  The  projections  of  these  BCNF  relations  to  eliminate  the  MVDs 
that  art’  not  also  FDs  will  produce  a  collection  of  4NF  relations. 

-  The  projections  of  these  4NF  relations  to  eliminate  the  JDs  that 
are  not  implied  by  candidate  keys  will  produce  a  collection  of  5NF 


relations. 


The  objective  of  this  reduction  process  is  to  reduce  the 
redundancy  and  to  avoid  problems  in  the  updating  operations. 

2.1.5  Keys 

The  primary  key  of  a  relation  R  is  an  attribute  or  a  set  of 
attributes  with  values  that  are  unique  within  the  relation  and  thus  can  be 
used  to  identify  the  tuples  of  the  relation.  If  the  relation  has  more  than 
one  attribute  carbination  possessing  the  unique  identification  property, 
they  are  called  candidate  keys.  A  candidate  key  that  is  not  the  primary  key 
is  called  an  alternate  key.  An  attribute  is  sometimes  called  a  foreign  key 
in  a  relation  if  its  values  are  values  of  the  primary  key  in  another 
relation. 

There  is  another  definition  for  the  key  of  a  relation  with 
functional  dependencies  (7) .  If  R  is  a  relation  scheme  with  attributes 
A^A^  • • -An  and  functional  dependencies  F,  and  if  X  is  a  subset  of  the 
attributes,  then  X  is  a  key  of  R  if: 

1.  X  — >  A ^2 . . .  A^  is  in  the  closure  of  F(F+). 

2.  For  no  proper  subset  Y  C  X  is  Y  — >  A-^.-.A^  is  in  F+. 

The  first  condition  implies  that  the  key  is  unique  within  the  relation.  The 
second  one  implies  the  minimality  of  the  key,  i.e.,  the  key  is  the  minimal 
set  of  attributes  that  functionally  determines  all  attributes. 


2.1.6  Armstrong's  Axioms  (7) 

Suppose  R  is  a  relation  schema  and  A,  B,  and  C  are  seme  of  its 
attributes.  Suppose  that  the  functional  dependencies  A  — >  B  and  B  — >  C 
are  hold  in  R.  Then  A  — >  C  must  hold  in  R.  So  A  — >  C  is  logically 


implied  by  the  set  of  functional  dependencies  F  for  a  relation  R.  Let  F+, 
the  closure  of  F,  be  the  set  of  functional  dependencies  implied  by  F,  i.e.. 
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F+  =  {X 


Y  |  F  |  =  x  — >  y} 


J 

Computing  F+,  the  closure  of  F,  is  essential  and  important  to 
determine  keys,  to  understand  logical  implications  among  F,  and  to  know 
whether  a  particular  functional  dependency  is  logically  implied  by  F. 

Armstrong's  axioms  are  the  set  of  rules  that  allows  us  to 
deduce  all  the  functional  depencencies  in  F+.  This  set  of  rules  is  ccnplete 
and  sound.  Ccnplete  means  that  it  allows  us  to  deduce  all  the  FDs  in  F+ 
and  sound  means  that  if  any  FD  is  not  in  F+,  then  it  is  impossible  to 
deduce  it  from  F  using  this  set  of  rules. 

Assume  that  there  is  a  relation  scheme  with  set  of  attributes 
U,  the  universal  set  of  attributes,  and  a  set  of  FDs  F  involving  only 
attributes  in  U.  The  set  of  rules  are: 

1.  Reflexivity:  If  YCXCU,  then  X  — >  Y  is  logically  implied  by  F. 

2.  Augmentation:  If  X  holds,  and  Z  C  U,  then  XZ  — >  Y  z  holds. 

3.  Transitivity:  If  X  — >  Y  and  Y  — >  Z  hold,  then  X  — >  Z  holds. 

There  are  other  rules  that  follow  from  Armstrong's  axioms.  They  are: 

1.  Union:  If  X  — >  Y  and  X  — >  Z  hold,  then  X  — >  YZ  holds. 

2.  Pseudotransitivity:  If  X  -t> Y  and  WY  — >  Z  hold,  then  XW  — >  Z. 

3.  Decomposition:  If  X  — >  Y  holds  and  Z  C  Y,  then  X  — >  Z  holds. 

2.1.7  Computing  Closures  (7; 10) 

In  general,  computing  F+  for  a  set  of  functional  dependencies 
F  is  a  time  consuming  task  because  the  set  of  dependencies  in  F+  can  be 
large  if  F  is  small.  Consider  the  set  F  =  {A  — >  B^,  A  — >  A  — >  Bn 

then  F+  includes  all  the  dependencies  A  — >  Y  where  Y  is  a  subset  of 
{ B, ,B~, . . . ,B  } .  As  there  are  2n  subsets,  F+  is  large  even  for  reasonable  F. 


But  computing  X+  for  a  set  of  attributes  X  is  not  hard.  It 
takes  time  proportional  to  the  length  of  all  the  dependencies  in  F  written 
out.  Also,  telling  whether  X  -->  Y  is  in  F+,  is  not  harder  than  computing  X+ 
Given  a  finite  set  of  attributes  U,  a  set  of  FDs  F  on  U,  and 
a  set  X  C  U,  the  following  algorithm  computes  X+. 

Algorithm  2.1 

1.  X+  =  X 

2.  While  F  includes  a  FD  Y  — >  Z  such  that  Y  C  X+  and  Z  £  X+  do 

X+  =  X+Z;  (X+  concatenated  with  Z) 

2.1.8  Covers  of  Sets  of  Dependencies 

Let  F  and  G  be  two  sets  of  FDs.  F  and  G  are  equivalent, 
written  F  =  G,  if  F+  =  G+.  If  F  and  G  are  equivalent,  then  F  covers  G  and 
G  covers  F.  The  following  algorithm  determines  if  F  and  G  are  equivalent. 
Algorithm  2.2 

1.  For  each  dependency  Y  — >  Z  in  F  do 

Compute  Y+  using  G 
If  ZC  Y+  then  Y  — >  Z  is  in  G+ 
else  F  ^  G,  stop 

2.  For  each  dependency  Y  — >  Z  in  G  do 

Compute  Y+  using  F 
If  Z  C  Y+  then  Y  — >  Z  is  in  G+ 
else  F  £  G,  stop 

A  set  of  functional  dependencies  F  is  minimal  if: 

1.  Every  right  side  of  a  FD  in  F  is  a  single  attribute. 

2.  For  no  X  — >  A  in  F  is  the  set  F-  {x  — >  A}  £F. 


For  no  X  — >  A  and  proper  subset  Z  of  X  is 


The  second  condition  guarantees  that  no  dependency  in  F  is 
redundant.  The  third  one  guarantees  that  no  attribute  on  any  left  side  of 
a  dependency  is  redundant.  The  following  algorithm  can  be  used  to  minimize 
the  number  of  dependencies  in  F,  that  is,  to  produce  the  minimal  F.  Each 
part  of  this  algorithm  corresponds  to  cne  of  the  previous  three  conditions. 


2.2  The  Network  Model 

The  network  model  consists  of  two  elements  only.  One  is  the  record 
type  and  the  other  is  the  set  or  link  between  record  types.  A  network 
schema  is  represented  as  a  directed  acyclic  graph  with  the  nodes  corres¬ 
ponding  to  record  types  and  edges  corresponding  to  sets  or  links.  An  edge 
is  directed  from  a  record  type,  called  the  owner,  to  another  record  type, 
called  the  rrember,  and  represents  a  many-to-one  relationship.  An  cwner 
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record  may  have  many  member  records  in  its  set,  but  a  member  record  has 
only  one  owner  record  of  a  particular  set.  Record  types  which  have  no  owner 
must  be  owned  by  the  system. 


The  record  type  is  a  collection  of  a  number  of  data  items.  The 
values  that  a  data  item  assumes  are  called  its  occurences.  The  occurence 
of  a  record  is  any  combination  of  the  occurences  of  its  constituent  data 
items. 

There  are  two  kinds  of  operations  for  the  network  model.  First,  there 
are  selections  on  logical  record  types  which  are  similar  to  the  selections 
on  relational  model.  The  other  type  of  operations  is  the  following  of 
links  in  one  direction  or  the  other. 

2.3  Comparison  Between  Relational  and  Network  Models  (4; 6) 

In  this  section,  the  relative  merits  of  the  relational  and  network 
approaches  will  be  discussed  as  a  basis  for  the  conceptual  view  of  the 
system.  The  comparison  will  be  concentrated  on  these  approaches  only 
because  the  hierarchies  are  considered  as  a  restricted  form  of  the  net¬ 
works  and  because  the  relations  and  networks  are  in  direct  competition  in 
the  database  field.  Although  the  discussion  is  concentrating  mainly  on 
the  conceptual  level,  several  of  the  points  are  also  related  to  the 
external  level. 

2.3.1.  The  Conceptual  Model 

The  conceptual  schema  should  serve  as  a  stable  base  for  the 
overall  system.  It  should  not  be  dependent  on  the  characteristics  of  any 
DBMS  so  that  it  can  handle  the  replacement  of  one  DBMS  by  another.  It 
should  not  have  to  be  changed  unless  some  adjustment  in  the  real  world 
requires  sane  definition  to  be  adjusted  too,  so  that  it  may  continue  to 


reflect  reality.  One  example  of  adjustment  is  the  expansion  of  the  con¬ 
ceptual  schema  to  reflect  a  larger  portion  of  reality. 

The  most  important  properties  of  the  conceptual  view  are 
the  following: 

1.  It  should  be  easy  to  understand  and  to  manipulate. 

There  are  many  aspects  that  help  in  achieving  an  easy  to  understand 
conceptual  view.  Sane  of  these  aspects  are: 

-  The  number  of  basic  constructs  should  be  small. 

-  Distinct  concepts  should  be  clearly  separated. 

-  Symmetry  should  be  preserved. 

-  Redundancy  should  be  carefully  controlled. 

The  aspects  that  help  the  conceptual  view  to  be  easy  to  manipulate 

are: 

-  The  number  of  operator  types  should  be  small. 

-  Very  high-level  operators  should  be  available. 

-  Symmetry  should  be  preserved. 

2.  It  should  have  a  good  theoritical  base. 

It  is  essential  that  the  conceptual  level  be  founded  on  a  solid  base  of 
theory.  Its  behavior  must  be  known  clearly  and  must  be  consistent  with  the 
user  expectations.  The  permitted  and  the  prohibited  must  be  fully 
determined.  Also,  it  is  important  to  know  all  the  problems  that  are 
expected  to  occur. 

2.3.2.  The  Relational  Model 

There  is  no  doubt  that  relations  are  easy  to  understand.  It 
uses  one  basic  data  construct,  that  is  the  relation.  Most  of  the  researches 
in  security  and  integrity  have  taken  the  relational  model  as  a  starting 


point  because  it  provides  a  clean  conceptual  view.  Also,  the  relational 
model  seems  to  meet  the  syrrmetry  and  non  redundancy  aspects.  The  normal¬ 
ization  guarantees  the  nonredundancy  in  the  conceptual  schema. 

Relations  are  also  easy  to  manipulate;  very  high-level 
operators  as  well  as  more  familiar  low-level  operators  are  available.  The 
high-level  operators  are  those  of  the  relational  algebra  and  equivalent 
languages.  The  number  of  distinct  operators  in  any  language  is  very  small 
because  there  is  only  one  data  construct  to  deal  with.  Also,  the  rela¬ 
tional  languages  provide  the  symmetric  exploitation  which  is  the  ability 
to  access  a  relation  by  specifying  known  values  for  any  combination  of  its 
attributes,  seeking  the  values  for  its  other  attributes. 

The  relational  approach  is  based  on  mathematical  set  theory.  Also, 
normalization  theory  provides  a  set  of  guidelines  for  the  design  of  a 
relational  schema.  The  theory  of  relational  completeness  provides  a 
valuable  tool  for  measuring  the  power  of  a  language  and  for  comparing 
different  languages. 

Most  relational  data  manipulation  languages  are  nonprocedural, 
that  is,  the  programmer  specifies  what  results  are  required  without 
specifying  how  the  system  is  to  access  the  database.  The  DBMS  is 
responsible  for  choosing  the  appropriate  access  paths.  Also,  nonprocedural 
languages  permit  accessing  many  records  for  each  command.  In  addition  to 
that,  one  relational  data  manipulation  command  can  be  constructed  by 
combining  other  commands.  Relational  commands  can  be  used  to  define  the 


database  views. 


2.3.3.  The  Network  Model 

Networks  are  somewhat  less  easy  to  understand  than  relations. 
In  DBTC,  there  are  five  data  constructs:  record  type,  DBTC  set,  singular 
set,  ordering,  and  repeating  group.  A  more  ccrp lex  problem  in  the  net¬ 
works  is  that  the  DBTG  set  construct  bundles  together  at  least  three 
distinct  concepts.  These  concepts  are: 

-  It  carries  information,  namely,  the  association  between  the  two 
record  types  involved. 

-  It  provides  an  access  path. 

-  It  represents  certain  integrity  constraints. 

A  network  schema  involving  sets  has  less  symmetry  of  representation  than 
an  equivalent  relational  schema,  since  seme  information  is  represented  as 
records  and  some  as  sets.  A  network  schema  can  be  just  as  redundant 
as  an  equivalent  relational  schema  if  it  does  not  involve  any  inessential 
sets. 

Networks  are  less  easy  to  manipulate  than  relations.  Each 
data  construct  needs  its  own  set  of  operators.  So  the  networks  require 
more  operators  than  relations.  Also  it  needs  more  integrity  constraints. 

There  is  no  theory  to  assist  with  the  design  of  a  network 
schema  that  is  as  complete  as  the  normalization  theory  is  for  relations. 
Normalization  theory  can  be  applied  to  the  records  of  the  network  but  only 
after  a  decision  has  been  made  as  to  which  information  is  to,  be  represented 
by  records  and  ’which  by  other  means. 

The  CODASYL  network  data  manipulation  language  is  a 
procedural  one  because  the  programmer  has  to  specify  how  the  DBMS  is  to 
access  the  database.  This  language  permits  the  programmer  to  access  a 


single  record  for  each  command.  Then,  he  may  access  either  another  record 
within  the  same  record  type  or  a  record  of  a  different  type  within  the  same 
set  as  the  current  record.  Also,  it  permits  the  programmer  to  take 
advantage  of  the  network  structure  by  writing  efficient  application  pro¬ 
grams  using  a  sequence  of  commands  to  specify  how  the  DBMS  is  to  access 
the  data. 

2.4  Multi-Model  DBMS 

A  multi-model  DBMS  must  meet  two  main  requirements:  it  must 
support  both  relational  and  network  schemas,  and  it  must  support  both 
procedural  and  nonprocedural  languages.  There  are  two  main  approaches 
to  achieve  that:  the  mapping  approach  and  the  composite  approach  (11) . 

The  mapping  approach,  illustrated  in  fig.  2.1.,  suggests  that  a 
schema  for  one  data  model  can  be  generated  frcm  the  schema  of  the  other 
data  model.  Data  manipulation  ccrnmands  against  the  generated  schema  are 
translated  to  equivalent  ccrmands  which  can  be  processed  against  the 
original  schema.  A  DBMS  in  which  a  relational  schema  can  be  napped  to  an 
underlying  network  schema  is  an  example  of  the  mapping  approach. 

The  composite  approach,  illustrated  in  fig.  2.2,  suggests  that  a 
schema  for  one  data  model  be  embedded  into  schema  of  the  other  model. 

The  resulting  came,  a  schema  contains  objects  which  can  be  viewed  as  both 
relational  and  network  objects.  Relational  and  network  data  manipulation 
commands  use  the  cannon  schema. 

From  the  user's  prospective,  there  is  no  main  difference  be¬ 
tween  the  two  approaches.  But  in  the  mapping  approach,  a  program  is 
restricted  to  one  type  of  caimand  while  in  the  ccrrposite  approach,  a  pro¬ 
gram  can  mix  network  and  relational  conmands. 


Fig  2.2.  The  Composite  Approach 


From,  this  brief  discussion  of  both  the  mapping  and  composite 
approaches,  it  is  clear  that  the  mapping  approach  is  the  suitable  one 
for  the  objective  of  this  thesis.  A  relational  schema  can  be  trans¬ 
lated  into  an  equivalent  network  one,  and  implemented  via  a  network 
DECS .  Translating  the  relational  data  manipulation  commands  into 
network  commands  which  is  already  discussed  in  some  researches  (9), 
will  achieve  the  multi-model  DBMS. 


III.  Translation  Algorithms 


There  are  two  algorithms  for  translating  a  relational  schema  into  an 
equivalent  network  one.  These  algorithms  were  developed  by  previous 
researchers.  In  this  chapter,  each  algorithm  is  explained  in  detail,  and 
used  to  solve  an  example.  This  example  is  chosen  such  that  it  illust¬ 
rates  every  step  in  both  algorithms.  The  two  solutions  are  compared  and 
one  algorithm  is  selected  as  a  basis  for  developing  the  required  auto¬ 
mated  technique.  It  is  important  to  mention  that  no  previous  researches 
attempted  to  develop  such  an  automated  technique. 

Both  the  algorithms  start  with  a  relational  schema  that  is  synthesized 
from  the  attributes  and  functional  dependencies  usaig  the  algorithms  in 
(16;19;20)  which  produce  relational  schemes  in  the  third  normal  form 
that  embody  the  FDs  as  keys  and  have  the  lossless  join  property. 

The  example  is:  Given  the  following  relational  schems,  generate  the 
equivalent  network  schema.  Keys  are  underlined. 

Rl(ABC) ,  R2(HDA),  R3 (DK) ,  R4 (KIA) 

R5  (PHI)  ,  R6  (KJB)  ,  and  R7  (PJ)  . 

3.1  Algorithm  I. 

3.1.1.  Algorithm  (10;14) 

The  steps  of  this  algorithm  are: 

1.  Create  a  record  type  hi  for  each  relation  schema  R^. 

2.  For  each  pair  of  record  types  (ifj) 

create  a  set  such  that  N.  owns  N.  if  R.  contains  a  key  of  R . . 


3.  For  each  pair  R^,  such  that 

(i)  Ri  C  Rj+ 

(ii)  There  is  no  directed  path  frcm  IR  to  I\R . 

(iii)  There  is  no  such  that  R^  C  R^+  C  Rj+,K^=j 
create  a  set  with  1R  cwns  IR . 

4.  For  every  JR  ,  remove  all  the  attributes  that  appear  in  an  ancestor  of 
M 

1* 

5-  While  a  new  record  type  is  created  do 

If  N^, ....  ,N^  (ro>l)  are  record  types  and  X  is  the  set  of  attributes 
that  appear  in  every  N^j  and  x  is  in  no  other  record  types,  then  create 
a  new  record  type  consisting  of  the  attributes  of  x  and  make  N,  the 
owner  of  every  NK . .  Delete  X  frcm  N^j .  Create  (X)  corresponding 
to  Nk. 

6.  For  every  KR ,  choose  one  key  x  of  such  that  all  attributes  contained 
in  X  are  also  in  IR  (not  every  fR  has  such  an  X) .  Make  X  a  key  of  !R 
with  duplicates  allowed. 

7.  For  every  IR  that  is  not  a  member  in  any  set,  create  a  system  owned 
set  with  Lb  as  the  member. 

8.  If  Ri  C  Rj+  and  there  is  no  link  frcm  IR  to  !SR,  then  create  a  set  with 
lb  as  owner  and  IR  as  member,  (optional) 

9.  Optionally  create  additional  system  owned  sets. 

10.  Search/ sort  keys  with  duplicates  may  be  created  freely  for  any  set  in 


.  the  network. 


Create 


record  type  I'h  for  each  relation  schema  i=l,2 


N^(DK)  (ABC) 


y 

m7  (PJ) 


M- (PHI) 


3.2  Algorithm  II 


To  understand  this  algorithm,  it  is  important  to  explain  two  special 
functions  that  were  defined  by  the  author  of  the  algorithm  (12) .  These  two 
functions  are:  MERGE  and  SPLIT.  Each  one  will  be  defined  and  explained. 

3.2.1  Special  Functions 

A.  MERGE  (S,N1,N2) 

S,  N^,  and  N2  are  sets  of  attributes  such  that  S  C  and  SCN^. 
and  are  in  the  form  of  networks,  i.e.,  they  each  constitute  the 
attributes  of  a  network  structure. 

The  operation  MERGE  puts  together  all  occurences  of  S  in  with 
all  occurences  of  S  in  N’2  without  duplicating  any  value.  The  operation 
maintains  the  proper  set  relationships  of  the  occurences  being  combined. 

In  general,  the  S -owner  sets  and  the  S -member  sets  for  S  in  may  be 
different  from  those  of  S  in  N2-  Let  Ch  denote  the  collection  of  S-cwner 
sets  and  denotes  the  collection  of  S -member  sets  for  S  in  NT,  i  being 

either  1  or  2.  MERGE  operates  in  such  a  way  that  when  it  is  done,  the 

collections  of  S-owner  and  S -member  sets  become  0^  U  C>2  and  U  M2 
respectively.  It  preserves  all  the  relationships  that  were  associated  with 
S  before  the  operation  either  in  or  in  N2« 

5.  SPLIT  (S.N) 

S  and  N  are  two  sets  of  attributes  of  some  relation  R  such  that 

S  C  N.  The  operation  separates  S  frcm  s\  where  s1  =  N-S,  and  sets  up  the 

proper  relationship  between  them.  In  effect,  N  is  converted  into  a  set 
with  S  and  s'1"  as  the  records  of  the  set,  except  in  some  situations  where 
two  sets  are  generated  and  an  additional  dunroy  record  is  used.  SPLIT  (S,N) 
may  result  in  the  following  types  of  sets: 
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« 


(a)  If  S  - >  s1  and  s1  -/->  S, 

the  set  is  formed  with  owner  s1  and  member  S. 

(b)  If  -— >  S  and  S  -/*■>  s^", 

the  set  is  formed  with  owner  S  and  member  s1. 

(c)  If  S  - >  s1  and  s^  - >  S, 

the  set  is  formed  with  either  S  or  s1  as  the  owner  and  the  other 
one  as  the  member. 

(d)  If  S  -/->  s1  and  s'*'  -/->  S,  a  dummy  record  is  created,  two  sets 
are  formed  -  one  with  owner  S  and  the  other  with  owner  S'*',  both 
having  the  dummy  record  as  the  member. 

Actually,  N  might  be  included  in  one  or  more  sets  as  a 
single  record.  SPLIT  must  maintain  the  proper  set  relationships  for 
these  sets. 

3.2.2.  Algorithm  (12) 

This  algorithm  has  two  parts:  A  and  B.  Each  part  will  be 
discussed  in  detail. 

(A)  This  part  finds  the  cornnon  attributes  from  a  given  relation-attribute 
(RA)  matrix  and  then  finds  the  carrion  attribute  groups.  The  algorithm  of 
this  part  is: 
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Begin 


1.  C  < - <j> 

2.  For  j=l  to  n  do 

Begin 

3.  find  the  no.  of  l's  in  column  j  and  call  it  COUNT 

4.  If  COUNT  >  1  then  C  =  C  U  {A^ } 
end 


5.  K  < - 1 

6.  While  C  f  <p  do 
Begin 


7. 

8. 

9. 

10. 

11. 

12. 


Select  any  attribute  frcm  C 

find  the  set  of  all  attributes  in  C  -  {Aj }  where  columns  in 
the  RA  matrix  are  identical  to  column  j 
Dk  < - {A.}  u  S 


D  <« 


C  -  C,. 


K  < - K+l 

end; 


G  < -  {D I  1  <P  <  K-l} 


end; 

Steps  2-4  pick  up  conmon  attributes  and  steps  5-11  form  the  cccnmon 
attribute  groups. 


I 


I 
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(B)  This  part  forms  the  network  schema  from  the  given  relational  schema.  The 
inputs  to  this  part  are  the  set  of  relations  in  3NF,  set  of  FDs,  and  the 
cannon  attribute  groups  G  generated  from  part  A.  is  the  set  of  attri¬ 

butes  for  i=l,2,...,m  and  at  each  stage  N  contains  attribute  groups 
processed  so  far.  The  algorithm  of  this  part  is 
Begin 

1.  N  < - b 

2.  For  i=l  to  m  do 

Begin 

3.  Find  all  groups  in  G  whose  attributes  are  element  of  ARi  and  call 
the  collection  of  these  groups  G^ 

4.  Order  Gi  in  such  a  way  that  the  groups  containing  candidate  keys, 
if  any,  are  placed  at  the  end. 

5.  While  Gi  f  4)  do 

Begin 

6.  Select  the  group  X  that  appears  at  the  beginning  of  Gi 

7.  Gi  < - Gl  -  X 

8.  If  X  =  ARi  then 

9.  if  XcN  then  MERGE  (X,ARi,N) 

10.  else  N  < -  N  U  X 

11.  else  Begin 

12.  SPLIT  (X,ARi) 

13.  If  XeN  then  MERGE  (X,ARi,N) 

14.  else  N  < - N  U  X 

end; 

15  •  *Ri  *Ri  -  x 

end  (while) 


end  (for) 


artsr  processing 

Only  the  set  indicated  by  ( - >)  in  the  previous  figure 


is  added  hi  this  setp. 


3.3  Solutions  Comparison 

Comparing  the  final  solutions  of  algorithms  I  and  II,  it  is  clear 
that  they  are  approximately  similar.  There  are  few  minor  differences  be¬ 
tween  them  but  these  differences  do  not  affect  any  property  of  the  designed 
network  schema.  These  differences  are  illustrated  in  table  3.1. 

No  Algorithm  I  Algorithm  II 

1  |  A  and  C  are  in  one  record  type 

! 

2  j  K  owns  I  and  J,  each  in  a  set  . 

i 

3  *  The  system  owns  K  and  B,  each 

;  in  a  set 

I  ! 

4  Number  of  record  types  is  9  , 

j  i 

5  j  Number  of  sets  is  12 

!  2 

6  |  Time  requirements  is  of  0(n  )  j 

i  i 

1  I 

7  ;  Space  requirements  is  of  0(n) 

i  i 

j  n  is  the  no.  of  relations 

_ L_ _ _ i 

Table  3.1.  Comparison  between  the  solutions 

From  the  final  solutions  of  both  algorithms,  and  frcm  table  3.1,  the  follow¬ 
ing  points  are  noticed: 

1.  Both  solutions  have  the  same  degree  of  nonredundancy  and  the  same 
relationships  between  record  types. 

2.  Both  solutions  have  the  same  time  and  space  requirements. 

3.  The  network  schema  generated  frcm  algorithm  I  has  a  small  number  of 
record  types  and  sets  than  that  generated  frcm  algorithm  II. 

4.  Steps  of  algorithm  I  are  simpler  and  easier  for  coding  than  those  of 
algorithm  II. 

For  the  above  reasons,  algorithm  I  is  chosen  for  develop  Lug  the 


A  and  C  each  is  in  a  separate  record 
and  A  owns  C  in  a  set 

Each  of  K,  I,  and  J  owns  the  duitiny 
record  in  a  set 

The  system  owns  K,  C,  and  B,  each 
in  a  set 

Number  of  record  types  is  10 
Number  of  sets  is  13 

2 

Time  requirements  is  of  0(n  ) 

Space  requirements  is  of  0(n) 


required  automated  technique  for  translating  a  relational  schema  into  an 
equivalent  network  one. 


IV.  The  Automated  Technique 
4.1  The  Modified  Algorithm 

After  discussing  algorithm  I,  which  is  chosen  to  develop  the  auto¬ 
mated  technique,  and  after  using  it  to  solve  an  example,  the  following 
remarks  are  appropriate: 

1.  Steps  1  to  7  are  the  essential  steps  in  the  algorithm  and  steps 
8,  9,  and  10  are  optional  steps  to  increase  the  efficiency  of  the 
generated  network  schema.  These  steps  8,  9,  and  10,  will  not  be 
considered  in  developing  the  automated  technique  only  for  the 
simplicity  reasons. 

2.  Step  2  in  the  algorithm  is  redundant  and  is  dominated  by  step  3 
because  if  contains  a  key  of  then  ^  C  R^+.  So,  step  2  can 
be  removed  from  the  algorithm. 

3.  Choosing  the  key,  that  is  step  6,  will  be  left  for  the  database 
administrator  because  it  is  very  difficult  to  deal  with  this 
problem  in  a  computer  program.  The  automated  technique  will 
try  to  keep  the  given  keys  of  the  relational  schema  as  long  as 
they  are  in  the  corresponding  record  types.  But  for  the  new 
record  types,  the  database  administrator  will  be  responsible 

to  choose  their  keys. 

Applying  the  previous  remarks  to  algorithm  I,  the  following  is  the 
modified  algorithm  which  will  be  used  to  develop  the  automated  technique 
for  translating  a  relational  schema  into  an  equivalent  network  one. 
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Algorithm 

1.  Create  a  record  type  th  for  each  relation  scheme  FL 

2.  For  each  pair  FL,  such  that 


3. 

4. 


(i)  Ri  C  Rj+ 

(ii)  There  is  no  directed  path  from  lb  to 

(iii)  There  is  no  R^  such  that  R^  c  R^+  C  Rj+,  K  ^  j 
Create  a  set  with  lh  as  owner  and  as  member. 

For  every  I\T  ,  remove  all  the  attributes  that  appear  in  its  ancestors. 
For  every  attribute  in  the  given  set  of  attributes  do 
If  the  attribute  appears  in  more  than  one  record  type 
then  -  create  a  new  record  type  consists  of  that  attribute. 

-  make  this  record  type  an  cwner  for  every  record  type 
contains  this  attribute. 


-  delete  this  attribute  from  the  record  types  containing  it. 
5.  Create  a  system  owned  set  for  every  N.  that  is  not  a  member  in  any  set 


4.2  Software  Development 

The  modified  algorithm,  mentioned  in  4.1,  is  developed  using  the  SADT 
included  in  Appendix  D  as  one  of  the  efficient  software  engineering 
techniques.  Then  the  structure  charts,  included  in  Appendix  A,  are 
developed.  The  basic  principles  of  software  engineering  are  considered: 
minimum  number  of  global  variables,  reasonable  number  of  modules  called  by 
each  module,  and  optimum  number  of  callings  for  each  module.  The  suitable 
data  structure  is  chosen  according  to  the  software  requirements.  The 
algorithm  of  each  module  is  designed  to  achieve  its  objective.  The  required 
software  is  developed  using  the  PASCAL  language,  and  tested  and  implemented 
under  the  UNIX  operating  system. 

4.2.1  Input  Parameters 

The  parameters  of  a  relational  schema,  which  is  the  input  to 
the  developed  software,  are:  number  of  relations,  number  of  attributes  in 
the  schema,  maximum  number  of  attributes  in  a  key,  and  the  maximum  number 
of  nonkey  attributes  in  a  relation.  To  develop  the  required  software,  the 
following  constants  are  assumed  at  the  declaration  part  of  the  software: 

-  maximum  number  of  relations  in  the  schema  (n)  is  10. 

-  maximum  number  of  attributes  in  the  schema  (m)  is  10. 

-  maximum  number  of  attributes  in  a  key  (11)  is  5. 

-  maximum  number  of  nonkey  attributes  in  a  relation  (12)  is  9. 

These  values  are  suitable  for  some  applications.  But  if  any 


of  the  parameters  of  an  application  exceeds  the  maximum  value,  the  value 
of  the  corresponding  constant  must  be  changed  to  suit  the  application 
otherwise  an  error  message  will  be  displayed  and  the  software  will  stop  the 


execution.  If  the  value  of  m  or  n  is  changed,  the  value  of  the  constant 
ran,  which  is  equal  to  m+n,  must  be  changed  also.  The  constant  mn  represents 
the  maximum  number  of  record  types  in  the  network  schema. 

4.2.2.  Data  Structure 

The  data  structure  used  in  the  developed  software  is  a  combina¬ 
tion  of  the  static  and  dynamic  types.  This  combination  is  chosen  in  such 
a  way  that  it  achieves  two  objectives:  to  be  simple  and  easy  to  under¬ 
stand,  and  to  use  the  necessary  amount  of  space  for  each  application.  In 
addition  to  that,  the  software  provides  the  user  with  the  ability  to 
change  the  values  of  the  constants  n,  m,  11,  12,  mn  at  its  declaration  part 
in  order  to  suit  the  application.  This  ability  minimizes  the  required  space 
for  an  application. 

The  main  part  in  the  data  structure  is  the  type  listl, 
illustrated  in  figure  4.1: 


record  type  relation 


keyattr  nonkeyattr  flag 


record 
type  sets 


tsets 


i 

record  type  relset 

mn 

pointer  pointer 

pr  ps 

type  listl 

Figure  4.1 

.  The  Structure  of  Type  listl 

The  data  structure  type  listl  is  an  array  (l..mn)  of  type 
relset.  Each  record  of  type  relset  represents  one  record  type  in  the  net¬ 
work  schema.  Listl  is  a  static  data  structure  with  respect  to  its  length 
and  mn  is  the  maximum  number  of  record  types  that  can  be  created  from  a 
relational  schema  with  parameters  n  and  m.  The  record  relset  consists  of 
two  pointers:  pr  and  ps  which  point  to  a  record  of  type  relation  and  sets 
respectively.  The  dynamic  point  in  the  data  structure  type  listl  is  that 
all  the  pointers  are  initialized  by  nulls  and  one  record  of  type  relset  is 
created  only  when  a  new  record  type  in  the  network  schema  is  created.  This 
means  that  at  any  time  the  number  of  created  records  of  type  relset  is  equal 
to  the  number  of  record  types  in  the  network  schema. 

The  record  type  relation  consists  of  the  following  fields: 

1.  Keyattr,  array  (1..11)  of  characters,  contains  the  key  attributes  of 
the  corresponding  record  type. 

2.  Nohkeyattr,  array (1.. 12)  of  characters,  contains  the  other  attributes 
in  the  record  type. 

3.  Flag,  character,  contains  a  control  value  during  the  execution  process. 

The  record  type  sets  consists  of  one  field,  that  is  tsets, 
which  is  an  array  (l..mn)  of  integers.  The  value  of  an  integer  is  used 
to  identify  if  there  is  a  set  between  two  record  types,  or  not.  The 
integer  rsli) .psA. tsets (j)  can  be  equal  to  0,  1,  or  -1  according  to  the 
following: 

-  0  if  there  is  no  set  contains  both  record  types  i  and  j. 

-  1  if  there  is  a  set  and  record  i  is  its  cwner. 

-  -1  if  there  is  a  set  and  record  i  is  its  member. 
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The  integer  rs(i)  .ps  .tsets(i)  is  equal  to  0  unless  if  the  record  i  is  a 
system  owned  record  then  it  is  equal  to  2. 

4.2.3  Input  Format 

The  developed  software  is  an  interactive  one.  This  means  that 
the  user  has  to  prepare  the  required  data  in  advance  before  using  the  soft 
ware  for  implementation.  The  data  will  be  input  to  the  software  through 
the  keyboard  when  the  user  is  asked  to  do.  Slight  modification  can  be 
done  to  the  software  in  order  to  read  the  data  from  an  input  file.  The 
required  input  data  are: 

1.  The  number  of  relations  in  the  relational  schema. 

2.  The  number  of  attributes  in  the  relational  schema. 

3.  The  attributes  of  the  schema. 

4.  For  each  relation  in  the  schema: 

i.  the  key  attributes 
ii.  the  other  attributes 

For  simplicity,  the  user  has  to  assign  one  character 
symbol  for  each  attribute  in  the  relational  schema  and  use  it  in  the  input 
of  data. 


4.2.4.  Output  Format 

As  mentioend  before,  in  section  1.4,  the  output  should  be  in 
an  understandable  form  so  that  the  user  can  easily  draw  the  network  schema 
and  implement  it.  The  output,  that  is  the  network  schema,  is  designed 
to  be  as  follows: 

1.  The  number  of  record  types. 

2.  The  number  of  attributes. 


3 .  The  attributes . 


4.  For  each  record  type  in  the  schema: 


i.  the  record  number 

ii.  the  key  attributes 

iii.  the  other  attributes 

iv.  for  each  set  includes  the  record  type 

-  the  numbers  of  record  types  included  in  the  set. 

-  the  owner  of  the  set. 

-  the  member  of  the  set. 

v.  if  the  record  type  is  a  system  cwned  record  or  not. 

4.3  Software  Testing 

To  test  the  developed  software,  the  necessary  checks  and  tests  are 
done  for  each  module  within  the  software  and  for  every  part  within  each 
module.  All  the  intermediate  results  are  displayed  during  several  runs. 

All  the  results  are  as  expected  and  as  supposed  to  be.  After  that,  the 
tests  sure  deleted  f rein  the  software  for  the  documentation  purposes. 

These  are  two  main  tests  in  the  software  to  check  the  correctness 
of  the  input  parameters  m  and  n.  Each  of  them  has  not  to  exceed  its  maximum 
value  explained  xn  4.2.1.  If  any  exceeds  this  value,  an  error  message 
will  be  displayed  and  the  program,  will  stop  the  execution  process. 

To  help  the  user  avoiding  this  type  of  error,  the  software  displays 
at  the  beginning  of  each  run  some  paragraphs  explaining  its  objectives,  the 
maximum  values  of  input  parameters,  and  what  the  user  can  do  to  change 
these  values.  The  complete  documented  software  is  included  in  Appendix  B. 


4.4 


Implementation 

The  developed  software  is  implemented  using  the  same  relational  schema 
mentioned  in  Chapter  3  as  an  input  to  be  translated  into  an  equivalent 
network  one.  The  resulting  network  schema,  included  in  Appendix  C,  is 
exactly  identical  to  the  manual  solution  of  Algorithm  I  in  3.1.2.  Also, 
all  the  tests  and  intermediate  results  are  coincident  with  the  correspond¬ 
ing  steps  of  the  modified  algorithm  in  4.1.  This  amp lementation  proves 
that  the  developed  software  achieves  its  objectives. 

In  addition  to  that,  the  software  is  implemented  using  different 
relational  databases.  The  generated  network  databases  are  efficient, 
i.e.,  have  the  necessary  and  sufficient  number  of  record  types  and  sets. 


V.  Conclusions  and  Reccnmendations 


5.1  Conclusions 

In  this  study,  an  automated  technique  for  translating  a  relational 
schema  into  an  equivalent  network  one  was  developed.  Several  important 
conclusions  were  reached  during  the  course  of  study.  They  are: 

1.  The  multi-model  DBMS  eases  many  problems  of  the  uni-model  one. 

There  are  two  approaches  to  achieve  the  multi-model  DBMS:  the 
mapping  approach  and  the  ccrrposite  approaches. 

2.  The  mapping  approach  is  the  suitable  one  for  the  conversion  applica¬ 
tions  because  it  suggests  that  a  schema  for  one  model  can  be 
generated  frcm  the  schema  of  the  other  model.  The  composite 
approach  needs  a  special  consideration  during  the  schema  design 
because  it  suggests  that  a  schema  for  one  model  be  embedded  into 
schema  of  the  other  model. 

3.  The  major  step  in  creating  a  multi-model  DBMS  frcm  a  network  one, 
is  the  translation  of  a  relational  schema  into  an  equivalent  net¬ 
work  one.  There  are  two  algorithms  that  were  developed  for  this 
purpose,  but  no  one  attempted  to  develop  such  an  automated 
technique . 

4.  Algorithm  I  (10; 14)  provides  the  simpler  methodology  for  the  trans¬ 
lation  process.  Also  the  generated  network  schema  is  simpler  and 
more  efficient  than  that  of  Algorithm  II  (12) . 

5.  Developing  such  an  automated  technique  is  an  important  and  necessary 
objective  because  it  is  a  big  step  toward  creating  the  multi-model 
DBMS,  and  it  facilitates  converting  relational  databases  into  net- 


vrork  databases. 


6.  This  technique  was  developed  using  PASCAL  as  one  of  the  most  ccnroon 
languages.  It  was  designed  to  be  user  friendly,  interactive,  and 
to  produce  a  network  schema  in  an  easy  and  understandable  form. 

7.  The  developed  technique  was  tested  and  implemented  using  the  same 
example  used  in  the  manual  solutions  in  3.1  and  3.2.  The  manual 
solution  of  algorithm  land  the  result  of  the  developed  technique 
were  identical. 

3.  The  automated  technique  was  designed  to  produce  an  efficient  net¬ 
work  schema.  There  is  no  redundancy  either  in  the  record  types 
or  in  the  sets,  and  that  keeps  the  number  of  record  types  and  sets 
minimum . 

Wj 
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5 . 2  Recommendations 


The  developed  automated  technique  can  be  efficiently  used  in  trans¬ 
lating  a  relational  schema  into  an  equivalent  network  one.  Based  on  the 
assumptions  stated  initially,  the  following  recommendations  are  proposed 
for  further  study. 

1.  Developing  an  automated  technique  for  converting  a  relational 
schema  to  its  third  normal  form.  This  conversion  is  necessary 
before  translating  a  relational  schema  into  a  network  one. 

2.  Developing  a  technique  for  displaying  the  resulting  network 
schema  in  a  graphical  form.  This  technique  will  help  the  user 
understanding  the  structure  of  the  network  schema  easily  and 
quickly. 

3.  Developing  an  automated  technique  for  mapping  the  relational 
carmands  to  equivalent  network  commands.  This  will  provide  the 
user  with  the  ability  to  access  the  database  using  either  rela¬ 
tional  or  network  commands. 

4.  Creating  a  multi-model  DBMS  frcm  a  network  one  using  the  results 
of  the  points  mentioned  before  together  with  the  automated 
technique  developed  in  this  thesis. 

5.  Results  of  points  1  and  2  can  be  used  to  modif y  the  automated 
technique  developed  in  this  thesis  effort  so  that  it  can  handle 
translating  a  relational  database,  that  is  not  in  the  third 
normal  form,  and  displaying  the  results  in  a  graphical  form.. 
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DATE  : 
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i  n  t  h  e  c  1 \> su  r e  o  ?  1  n  0  t  ■'•■  0  -  :.■• n  c  ,  3  c 
i  n  c  a  n  y  a  v.  t  r  i  b  u  1 0 *  t  n  0  5  ~ :  :  c  0  0  >1  r  e 
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OUTPUT? 
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is 
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CALLED 

♦ 
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CALLING 
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l 

•V 

CALLING 

MODULE 
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f. 

ALT  M 0 R 

♦ 

*: 

HISTORY 

♦ 
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;V 
t ' 


y  y  :«•  ;r  ^  v  *  <*  $  y  ■), 


11  ~i  ■  1 . ^ , 


BATE  :  1  *‘9/84 

DEES  103  •  .  0 

Kr»Z  :  Procedure  caiciosure 

.inr.'  iL:-  » Ur‘B!::;  -  I  3  .  1 

-  •....  ;  c  7  I  V  -I  7  r ;  C  ....  .j.  ,j  r  .;  ;.  h  ■?  C  I  Q  ~  '  .1 

"r-n-,uTS  ’  '  * •  a  l 

ou'"PUrs  ;  c 


3LCB.AI. 

LAEIABL 

i£  3  »j  3  j£  & 

:  r  ;> t  c  v  n  1 

OLGI-Al. 

VARIABL. 

es  change: 

D  '  c 

GLOBAL 

TABLES 

USED 

; 

.  '  ’•  B  A ! 

TABLES 

C  F  ^  N  G  E.  D 

* 

j:;'  t  £  Q 

READ 

* 

... 

WRITTEN 

♦ 
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MODULE 

8  CALLED 

:  Pro 

c  oduros  1  oa  J  i  •.•  1 

eac  2 

'ALL IN G  MODULES  » 

p*  O  C  C1  rt  U  T*‘  T:?  1'  r 

e  a  s 
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l 
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o  s?  a  i  n 

..,.1  i  ’ 

1 '  J.  J  [  ♦ 

.?  •;  '  .  i<  •>•,/,> 

•  i  -  , 
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r  l 
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t  h  e  n  n  © 
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"1 
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1 A  *•  i 

e  vo. 

i  1 

r  -  1 

:?  n  d 
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*  > 

-■  -J.:.  r 

,  p  y  i  _  ! 

"t  n  o  f; 
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Vl  h  i  ).  l2  (  (  < 
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if  <?  u  ♦  .* 

<  0  V 

■  1 1  r  C  i 
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b  0  q  i  n 

y  .1 

u  f  K 

end 

a  1  s  a 

.1  *  — 

i  i- 

•f 

1  V 

ends  ( *  i P 

*  ) 

end  i  k  *.  if  HO 

■*'  i  >  r-  :■■■  r  d 1  i  p fj  3  1 

«k  + 

renatt 

¥  x  %  X  X  ifc  X.  X  'r-  X  M.  X  X.  /<*  X.  X  X  X  X  X  Y  X.  ?.  X  X  X  T-  X  &  X  Jf.  %  X  X.  :<;  %  ;{c  )'f.  X  X.  *■  K  A  K  • 


HATE  :  A/ 9/8 T 

VERSION  *  1*0 

N A M E  *  P rocs d '.ire  r e m o v o •.; t x r 

MODULE  MUM SLR  :  4 

c'UHCTION  l  For  each  record  xype  .tie  a 

a n y  a  t  r.  r ibu  t o  > h a  r.  a 1 ; q a  - s 
INPUTS  !  rs.nl 

OUTPUTS  :  rs 

GLOBAL  VARIABLES  USED  t  ro.nl 

GLOBAL  VARIABLES  CHANGED  5  rs 

GLOBAL  TABLES  USED  ‘ 

GLOBAL  TABLES  CHANCED 

“ILES  READ  *  ~ 

PILES  WRITTEN  ? 

M 0 D U I.  E 3  C A l.  LED  *  Proc  e d  a  r « s  d  e  let  reo  0.  x  x 

CALLING  MODULES  I  Main  progra 

A  U  T  !■ 1 0  R  !  M  ci ,  j  <•  E I  s  a  y  &  0  Y  a  s  e 

HISTORY 
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DATE 

VERSION 
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PILES  WRITTEN  : 
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CALLING  MODULES  X 
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HISTORY  : 


at  t name 
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i  a  ,j  :  E I  e  a  y  e  d 
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cna ;  ( *  while  *  > 

If  <  >*2=0)  then  w ri  te <  '  NONE  '  )  J 
for  .j  ;  ~ .1  to  3  do 
w  r  x  t  e  i  n  % 

x  x  !. 0  •  I'ind  \  '  2  =0  1  1  '.hen 

write! nt'  This  record  %».*pe  is  a  lint  between  os  her 
e  n  d  J  *  w  i.  t  h  * ) 

w  1 1  n  r  s  l  i  l1  >  p  s  A  d  o 
f  o  I  1  to  n  1  d o 
b  e  u  l  n 

i f  i t  s e t s l  .  j  3 ~ i )  then 
b  e  cj  i  n 

>,  i  r  i  t.  e  L  n 
w  r  i  t  e  i  n  J 

write-in  ( /There  is  a  set  between  roco'-a  types  no' 
writein  <  '  The  owner  of  this  set  is  the  record  no' 
w  rioeln  (  '  The  member  in  this  sec  is  tHe  record  no 
end;  <*  if  St) 
i  f  ( t  s  etsll.j  1  ~  -■  1 )  t  h  e  n 
beg  in 

w  r  1 1  e  .1  n  { 
w  i  t  e  i  n  } 

writein  < "There  is  a  sec  oe tween  record  types  no- 
writein  (  'The  owner  of  true  sec  is  tne  "scord  no' 
writein  < 'The  member  in  this  set  is  the  record  no 
e  n  a  J  ( *  i  f  -i< ) 
i  f  ( t  s  e  t  s  II .  j .]  -  2  >  1 1  -i  e  n 
b  e  q  x  n 

v  r  j.  i  s  1  n  * 
w  r  i  t  e  !.  n  J 

w r 1 1 e x n  <  ■'  Th i  *  is  a  s y s t e m  o v»n e d  r e c o r c  v. v  ■  e  "■  ’• 
writ e i n  J 

on  *  *'  A  ■*  •{•'  #  * 

-  ; 5  l  (  P  r;.  r  * 
j  p  >  ■■  *•  “j  r-  <  \ 

w  1 1  e  1  n  ; 
w  r  1 1  e  1  n  J 

jr  i  rein  (  '  THIS  IS  T,Ji-  £  t'ft  OF  ril'\  H:.„  f'jOHK  SC  Hi.  H,Jt  '  '*  • 

p  :  •  *  p  r  o  c  e  <1  u  r  o  r  e  s  uH  s.  * 


Appendix  C 

Resulted  Network  Schema 


rn  TO  r'  R  0  G  R  A  M  TRANSLATE 


He  FUNCTION  r  r-  THIS  PRO  OR  AM  is  to  translate  a  relational 
ENEMA  INTO  AN  EQUIVALENT  NETWORK  ONE  .  THE  PROGRAM  IS 
ESI  ONE!’  TO  HANDLE  A  RELATIONAL  SCHEMA  WITH  THE  FOLLOWING 
A  E  A  M  E  I  E  R  S  * 


AX.  NO. 

Or 

PEL AT I CMS  F 

r,  1 

t  r* 

x  o 

10 

A''  >  NO  „ 

ATTRIBUTES 

L  :ti  j 

IS 

10 

A',  NO. 

n  nr 

KEY_ATTR.  C 

111 

IS 

r~ 

j 

AX.  NO. 

OF 

NONKEY _ A "TR 

.  Cl 

21  I 

P,  9 

A'-'.  NO, 

OF 

RECORD "TYPE 

S  IN 

THE 

GENERATED 

SCHEMA 


in  :i  TS  20  WHICH  IS  EQUAL  TO  m+n 


AN  /  OF  YOUR  SCHEMA  PARAMETERS  EXCEEDS  THESE  MAX,  VALUE 
LEASE  MODIFY  THE  CORRESPONDING  CONSTANTS  AT  THE  DECI...ARAT 
AFT  OF  THE  PROGRAM  TO  SUIT  YOUR  NEEDS  . 


THANK  YOU 


THIS  IS  THE  EQUIVALENT  NETWORK  SCHEMA 

THE  NO.  OF  RECORD  TYPES  IS  ? 

THE  NO.  OF  ATTRIBUTES  IS  ? 

THE  ATTRIBUTES  ARE  J  abcdhjkip 


THIS  IS  THE  RECORD  TYPE  NO.: 


The  Key  attributes  of  this  record  are  a 

The  nonKey  attributes  of  this  record  are  c 


There  is  a  set  between  record  types  no  1  and  no 

The  owner  of  this  set  is  the  record  no  1 

The  member  in  this  set  is  the  record  no  2 

There  is  a  set  between  record  types  no  1.  and  no 

’"he  owner  of  this  set  is  the  record  no  l 

The  member  in  this  set  is  the  record  no  A 

There  is  a  set  between  record  types  no  1  and  no 

The  owner  of  this  set  is  the  record  no  8 

The  member  in  this  set  is  the  record  no  1 
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THIS  IS  THE  RECORD  TYPE  NO 


♦  n 

♦  *  .V.. 


The  Key  attributes  of  this  record  are  h 

The  noriKey  attributes  of  this  record  are  NONE 


There  is  a  set  between  record  types  no  2  and  no 

The  owner  of  this  set  is  the  record  no  1 

The  member  in  this  set  is  the  record  no  2 

There  is  a  set  between  record  types  no  2  and  no 

The  owner  of  this  set  is  the  record  no  3 

The  member  in  this  set  is  the  record  no  2 


There  is  a  set  between  record  types  no  2  and  no 

The  owner  of  this  set  is  the  record  no  2 

The  member  in  this  set  is  the  record  no  5 


THIS  IS  THE  RECORD  TYPE  NO.J  3 


The  Key  attributes  of  this  record  are  d 

The  nonKey  attributes  of  this  record  are  NONE 


There  is  a  set  between  record  types  no  3  and  no 

The  owner  of  this  set  is  the  record  no  3 

The  member  in  this  set  is  the  record  no  2 

There  is  a  set  between  record  types  no  3  and  no 

The  owner  of  this  set  is  the  record  no  9 

The  member  in  this  set  is  the  record  no  3 


\  b  rei'ord  tvpes 

.1:  Be-  is  the?  record 
.1  .a  |  it  1  h  1  7,  jet  the  r.?co,'cl 

e  i  '■■■■  ~i  oet  h  e  tween  record  types 
owi"-  a  r  of1  t  h  •*  Bet  i.  the  record 
■?i ember  in  bh  t  »  ~et  .1  -  the  record 

e  i«  >i  Bet  between  record  types 
owner  oP  t  !.  l  e  :>e  t  is  the  record 
fie  ri.) er  m  t h i c  ?  t  i  s  the  record 


r  ■  r  3  the  r r :: c r d  t y p e  n o  * : 
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The  member  in  this  set  is  the  record  no  6 
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Translate  A  Relational  Schema  into  a  Network  One 


A-0  TRANSLATE :  Translate  a  Relational  Schema  into  an  Equivalent  Network 
One 

This  is  the  entire  software.  It  translates  a  relational  schema  into 
an  equivalent  network  one.  It  is  an  interactive  software,  i.e.,  the  user 
has  to  enter  the  relational  schema  as  an  input  through  the  keyboard. 

If  there  is  an  input  error,  an  error  message  is  displayed  and  the 
software  stops  the  execution.  In  case  of  correct  input  data,  the  generated 
network  schema  is  displayed  on  CRT  and/or  printed. 


AO  TRANSLATE:  Translate  a  Relational  Schema  into  an  Equivalent 
Network  One 

The  entire  software  is  decomposed  into  the  following  seven  major 
components: 

1.  Check  input:  It  checks  that  the  number  of  relations  and  the  number  of 
attributes  of  the  relational  schema  are  within  the  range  of  the  software. 
If  any  of  them  exceeds  the  max.  value,  an  error  message  is  displayed  and 
the  software  steps  execution. 

2.  Input  data:  It  takes  the  relational  schema  as  its  input  and  creates 
a  record  type  for  each  relation. 

3.  Create  sets:  It  creates  the  proper  sets  between  the  record  types 
according  to  step  2  in  the  algorithm  in  section  4.1. 

4.  Remove  repeated  attributes:  For  every  record  type,  it  removes  all  the 
attributes  that  appear  in  its  ancestors. 

5.  Cannon  Attributes:  For  any  common  attribute,  it  creates  a  new  record 
type  consists  of  that  attribute,  deletes  the  attribute  from  the  record 
types  containing  it,  and  creates  the  proper  sets  between  the  new  record 
type  and  the  other  record  types. 

6.  Create  System  Sets:  It  creates  a  system  owned  set  for  every  record 
type  that  is  not  a  member  in  any  set. 

7.  Results:  It  produces  the  generated  network  schema  in  an  understand- 


A3  CREATE  SETS 


This  part  of  the  software  creates  the  proper  sets  between  the  record 
types  according  to  step  2  in  the  algorithm  in  4.1.  It  consists  of  the 
following  three  ccrponents: 

1.  Calculate  closures:  It  calculates  the  closure  of  each  relation 
corresponding  to  the  record  type 

2.  Checkl:  For  each  pair  and  ,  this  module  checks  that  c  R^ 
and  there  is  no  directed  path  from  to  .  If  these  two  conditions 
are  correct,  the  module  sets  up  the  control  variable  checkl  status. 

3.  Check2:  This  module  is  controlled  by  the  variable  checkl  status. 

1c  checks  that  there  is  no  R^  such  that  R.  c  R^c  R*,  and  K  ^  j. 

If  this  check  is  correct,  the  module  creates  a  set  such  that  N.  owns  N.. 


Calculate  Closures 


A31  CALCULATE  CLOSURES 


I 

This  part  of  the  software  calculates  the  closure  of  each  relation  in 
the  relational  schema.  This  can  be  done  through  the  following  steps: 

1.  loadl:  It  loads  the  key  attributes  of  each  relation  R^  in  its 
closure  R 

2.  load2:  It  loads  the  ncnkey  attributes  of  each  relation  in  its 
closure  R^+. 

3.  Canpare:  For  each  relation  R and  for  j  =  i  4=  j ,  this  module 

checks  that  c  R^+.  If  this  condition  is  satisfied,  the  module  sets 
up  the  comparison  status. 

4.  load3:  This  module  is  controlled  by  the  comparison  status  variable 

+  + 

If  any  attribute  in  Rj  does  not  exist  in  R^  ,  the  module  adds  it  to  R^  . 

Steps  3  and  4  are  repeated  until  it  is  sure  that  no  new  attributes 

will  be  added  to  R/1’. 
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Remove  Repeated  Attributes 


A4  REMOVE  REPEATED  ATTRIBUTES 


For  each  record  type  tT,  this  part  of  the  software  deletes  all  the 
attributes  that  appear  in  the  ancestors  of  that  record  type.  This  is  dene 
in  the  following  two  steps: 

1.  find  repeated  attribute:  This  module  looks  for  an  attribute  that  is 
repeated  between  a  record  type  and  one  of  its  ancestors. 

2.  delete  repeated  attribute:  This  module  deletes  the  repeated  attribute 
frcm  the  record  type. 


Cannon  Attributes 


A5  COMMON  ATTRIBUTES 


This  part  of  the  software  executes  the  fourth  step  in  algorithm  4.1 
This  step  is  done  by  two  modules.  They  are: 

1.  Find  a  cannon  attribute:  For  each  attribute  in  the  network  schema, 
the  module  checks  if  it  appears  in  more  than  one  record  type.  In  this 
case  the  module  sets  a  flag  in  each  record  type  contains  that  attribute. 

2.  Modify  record  types  and  sets 

For  each  cannon  attribute,  this  module  does  the  following: 

-  create  a  new  record  type  consists  of  that  attribute 

-  make  the  new  record  type  an  owner  for  every  record  type  contains 
that  attribute 

-  delete  the  attribute  from  the  old  record  types. 
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This  thesis  developed  an  automated  technique  for  translating  a  rela¬ 
tional  schema  into  an  equivalent  network  one.  In  addition  to  the  usual 
translation  applications,  this  technique  is  the  major  step  towards  develop¬ 
ing  the  multi-model  data  base  management  system  which  enables  implementing 
both  relational  and  network  databases  via  one  system,  allows  the  use  of 
either  relational  or  network  corrmands,  solves  the  problem  of  converting 
applications,  and  eases  the  conmunication  between  data  base  management 
systems. 

< 

Reviewing  the  previous  efforts  in  that  field,  there  are  two  algorithms 
that  were  developed  for  the  same  objective.  Each  one  was  discussed, 
explained,  and  used  to  solve  an  illustrative  example.  Both  algorithms  were 
compared  and  one  of  them  was  chosen  as  a  basis  for  developing  the  au tana ted 
technique . 

The  chosen  algorithm  was  modified  to  suit  the  requirements,  and  analyzed 
and  decomposed  using  the  SA0T,  The  au tcma ted  technique  was  developed  and 
coded  in  PASCAL.  In  its  development,  it  was  consisered  to  be  user  friendly, 
and  to  produce  the  network  schema  in  a  suitable  format.  The  developed 
technique  was  tested  and  implemented  using  a  relational  schema  in  the  third 
normal  form.  The  resulting  network  schema  was  efficient,  nonredundant,  and 
had  the  minimum  and  necessary  number  of  record  types  and  sets  as  it  was 
supposed  to  be. 

Several  conclusions  were  reached  during  the  course  of  study,  and  some 
recommendations  were  proposed  for  further  study  according  to  the  assumptions  t 

listed  initially.  “i 
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